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WHOIS Protocol Specification 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This document updates the specification of the WHOIS protocol, 
thereby obsoleting RFC 954. The update is intended to remove the 
material from RFC 954 that does not have to do with the on-the-wire 
protocol, and is no longer applicable in today’s Internet. This 
document does not attempt to change or update the protocol per se, or 
document other uses of the protocol that have come into existence 
since the publication of RFC 954. 


1. Introduction 


WHOIS is a TCP-based transaction-oriented query/response protocol 
that is widely used to provide information services to Internet 
users. While originally used to provide "white pages" services and 
information about registered domain names, current deployments cover 
a much broader range of information services. The protocol delivers 
its content in a human-readable format. This document updates the 
specification of the WHOIS protocol, thereby obsoleting RFC 954 [1]. 


For historic reasons, WHOIS lacks many of the protocol design 
attributes, for example internationalisation and strong security, 
that would be expected from any recently-designed IETF protocol. 

This document does not attempt to rectify any of those shortcomings. 
Instead, this memo documents the WHOIS protocol as it is. In some 
areas, this document does document particular well known shortcomings 
of the WHOIS protocol. The discussion of possible protocols to carry 
out these functions, with updated capabilities to address the 
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shortcomings, is being addressed in a separate IETF activity (CRISP 
Working Group). 


2. Protocol Specification 


A WHOIS server listens on TCP port 43 for requests from WHOIS 
clients. The WHOIS client makes a text request to the WHOIS server, 
then the WHOIS server replies with text content. All requests are 
terminated with ASCII CR and then ASCII LF. The response might 
contain more than one line of text, so the presence of ASCII CR or 
ASCII LF characters does not indicate the end of the response. The 
WHOIS server closes its connection as soon as the output is finished. 
The closed TCP connection is the indication to the client that the 
response has been received. 


3. Protocol Example 


If one places a request of the WHOIS server located at whois.nic.mil 
for information about "Smith", the packets on the wire will look 


like: 

client server at whois.nic.mil 

open TCP Sats (SYN) (SaaS ae RSS Sr RSS Se RSS > 
<---- (SYN+ACK) ----------~-~-------------- 

send query ---- "Smith<CR><LF>" -------------------- > 

get answer <---- "Info about Smith<CR><LF>" --------- 
<---- "More info about Smith<CR><LF>" ---- 

close STERS (BIN): SHsssaSHsses seas Saas Saas Saeae= 
----- (FIN) -----------------------------> 

4. Internationalisation 


The WHOIS protocol has not been internationalised. The WHOIS 
protocol has no mechanism for indicating the character set in use. 
Originally, the predominant text encoding in use was US-ASCII. In 
practice, some WHOIS servers, particularly those outside the USA, 
might be using some other character set either for requests, replies, 
or both. This inability to predict or express text encoding has 
adversely impacted the interoperability (and, therefore, usefulness) 
of the WHOIS protocol. 


5. Security Considerations 
The WHOIS protocol has no provisions for strong security. WHOIS 
lacks mechanisms for access control, integrity, and confidentiality. 


Accordingly, WHOIS-based services should only be used for information 
which is non-sensitive and intended to be accessible to everyone. 
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The absence of such security mechanisms means this protocol would not 
normally be acceptable to the IETF at the time of this writing. 
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This document is subject to the rights, licenses and restrictions 
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